FOAF：本可以成為 Facebook

我把自己的社交網路寫進 FOAF 文件，這就是變革之始。—— 互聯網之父蒂姆·伯納斯·李（2007）

FOAF 標準（ 朋友的朋友 Friend of a Friend ），是一個可以追溯到本世紀初的網路標準，目前它基本上已經不再使用了，或者說被人們忘記了，亦或者說已經被取代了 ^[1] 。它暗示了，假如 Facebook 沒有征服世界的話，FOAF 將會定義我們今天所用的社交網路。不過在開始探討這一網路標準之前，我想先來談一談紐約地鐵。

目前，紐約地鐵的唯一管理機構是 大都會運輸署 Metropolitan Transportation Agency （簡稱 MTA）。MTA 壟斷了紐約市的地鐵交通。在紐約乘地鐵必須先從 MTA 購買車票，否則屬於非法行為。也就是說，MTA 在地鐵行業沒有任何競爭對手。

不過，以前可不是這樣。說起來可能有些讓人吃驚，紐約市的地鐵交通曾由兩家企業相互競爭，共同運營。 跨區捷運公司 Inter-borough Rapid Transit Company （IRT）的勢力範圍是穿過曼哈頓的線路， 布魯克林-曼哈頓運輸股份有限公司 Brooklyn-Manhattan Transit Corporation （BMT）管理的則是布魯克林區內的線路，其中也有部分線路延伸到了曼哈頓。1932 年，紐約市開通使用了自己的服務，稱為獨立地鐵系統，與 IRT 和 BMT 展開競爭，所以當時紐約共有三家不同公司控制著市內地鐵交通。

可能會有人覺得這樣的地鐵運營效率不高。事實上也確是如此。由於 IRT 和 BMT 投入使用的列車寬度不同，所以在不同的運營系統之間建造換乘站十分困難。此外，乘客換乘時還需向不同的運營商支付費用，這就意味著在換乘站至少要設置兩個不同的檢票區域。後來，紐約市於 1940 年接管了 IRT 和 BMT，將整個紐約市的地鐵交通置於一家運營商的管理之下，不過由於此前分而治之而造成的效率低下問題時至今日依然存在：能在 BMT 的線路上（如 A、C、E 號線）運行的列車無法在 IRT 的線路上（如 1、2、3 號線）運行，因為 IRT 的線路隧道比較窄。因此，MTA 不得不同時管理這兩種互不兼容的列車系統，由此帶來的支出可能遠比世界上其他單一隧道寬度的地鐵系統要多得多。

IRT 和 BMT 之間的競爭所造成的歷史遺留問題告訴我們，地鐵系統本身就趨向於壟斷經營。相比較於兩家運營商相互競爭，只有一家運營商更能解決問題。乘客們雖然失去了選擇的餘地，但再也不用擔心帶了一張地鐵卡卻忘記了另一張的問題。

那麼，地鐵和社交網路又有什麼關係呢？我在想，Facebook 是否和 MTA 一樣都有自然壟斷的屬性呢？事實上，無論是自然壟斷還是非自然壟斷，Facebook 貌似確有壟斷能力。當然它壟斷的不是社交媒體本身（我在 Twitter 上面花的時間更多），而是壟斷了與現實中認識的人之間的線上聯繫。Facebook 能夠壟斷所謂的「社交圖譜」；如果我不用擔心會失去與別人的聯繫方式，那我明天就會卸載 Facebook。我對 Facebook 對我身上的這種壟斷權力感到非常氣憤。不過，我卻不會生 MTA 的氣，即便從字面上和隱喻上來講，紐約市地鐵都是一堆焚燒著的、火舌亂竄的垃圾。說到底，我憤怒是因為我覺得不同於 MTA 的自然壟斷，Facebook 的壟斷屬於非自然壟斷。

我的意思是，如今 Facebook 之所以能擁有所有人的社交數據，因為它碰巧是第一個做大做強、確立巨頭地位的社交平台，而不是因為其他社交平台難以或者無法與之競爭。不過，難道真是因為這樣嗎？許多事實告訴我們，原因並非如此。Facebook 僅僅是先入為主，還是它提供的服務真的比其他社交平台要好？如果你想聯繫老朋友，只有 Facebook 這一個平台的話，不會方便許多嗎？在一個有幾個 「Facebook」 相互競爭的情況下，如果你和你男朋友 Facebook 上面的感情狀態都顯示「交往中」，但是他始終沒來得及更新他在 VisageBook 上的感情狀態，那上面現在還顯示著他和他大學前任的關係，那麼這種情況意味著什麼呢？人們信任的又是哪個社交網站呢？如果社交網站有很多，難道在填寫信息上面不會很耗時間嗎？

過去幾年，由於中心化社交網路的缺陷暴露出來，許多人嘗試構建去中心化的平台。基於開放標準，去中心化平台有望建立互通的社交網路生態（比如 Fediverse）。可惜的是，其中沒有一個平台能夠取代主流社交網路。一個比較明顯的原因是 網路效應 network effects 的力量：既然每個人都在用 Facebook，那麼任何想要放棄 Facebook 的人都將會付出巨大的代價。有人會說，這一點恰恰證明了社交網路屬於自然壟斷行業。但我想說，Facebook、Twitter 等平台是自己選擇封閉起來的。此外，鑒於人們已經設想出社交網路的互通性，並且付諸實踐，那麼封閉的社交平台引發的網路效應就無法證明社交網路具有自然壟斷屬性。

因此，在我看來，真正的問題是：之所以 Facebook 等平台到現在仍是主流社交網路，僅僅是因為網路效應，還是說與只有一家運營商的地鐵系統一樣，單一的主流社交網路效率更高？

最後，這些問題讓我想起了 FOAF。儘管人們似乎已經忘記了 FOAF 標準，但是早在 Facebook 出現之前，人們就嘗試使用 FOAF 建立開放的、去中心化的社交網路。如果過去有哪個去中心化社交網路有機會早於 Facebook 佔領如今它駐守的陣地，那隻可能是 FOAF。考慮到世界上大部分人都有 Facebook 賬號，而且了解 FOAF 的人相對較少，我們是否可以得到如下結論：同地鐵一樣，社交網路也有中心化和自然壟斷的性質；亦或者，FOAF 項目說明，儘管去中心化社交網路可行，但由於其他原因，無法獲得人們的廣泛支持。

早期社交媒體的未來

FOAF 項目誕生於 2000 年，旨在建立一套表示個人身份以及人與人之間關係的通用標準。在今天看來，這一雄心勃勃的項目可能會讓人感到驚訝，但是在上世紀末本世紀初，這樣的想法再尋常不過了。當時 網路 Web （當時人們仍然這樣稱呼它）剛剛擊敗了 美國在線 America Online 與 Prodigy 等封閉系統。這讓人很自然地想到，計算機領域的創新發展必須要保持開放、基於標準，而且這也正是網路的特點。

許多人認為，網路下一場重頭戲會是 語義網 Semantic Web 。我有篇文章介紹了關於語義網概念與運行原理的設想，所以這裡不再贅述。但是我會簡單談談推動人們研究語義網技術的願景，因為 FOAF 標準正是這一願景在社交網路方面的應用。

一篇題為 《 谷歌如何擊敗亞馬遜和易貝，朝著語義網進軍 How Google beat Amazon and Ebay to the Semantic Web 》 的文章很好地描繪了語義網這一崇高理想。文章寫於 2002 年，作者是 Paul Ford。這篇文章設想了 2002 年至 2009 年的情景：通過使用語義網，谷歌取代了亞馬遜和易貝，成為電商平台主導者。文章指出，在未來，如果你想買東西，比如說一把二手的馬丁吉他，可以在谷歌中輸入 buy:martin guitar。根據你的郵編，谷歌會告訴你附近哪些人在賣馬丁吉他。谷歌之所以可以獲取賣家及其吉他的信息，是因為它可以讀取資源描述框架標記語言（RDF），該語言是語義網的核心技術，用於描述資源之間的關係。人們可以將 RDF 內容嵌入網頁，能實現很多用途，比如給要賣的東西打廣告。Ford 預測，隨著使用這種方式搜索和售賣商品的人數增加，亞馬遜和易貝將失去它們在電商領域近乎壟斷的地位。如果可以搜索全網，又有誰會執著於某個封閉的資料庫呢？Ford 寫道，即便是谷歌，最終也會失勢。因為理論上，任何一個人都可以檢索網路，查閱 RDF，提供類似於谷歌的搜索功能。起碼，如果谷歌打算對語義網上的每筆交易按一定比例收取費用，以此盈利，那麼以後隨著相關競爭越來越激烈，谷歌的抽成比例很有可能會被迫降低。

Ford 所設想的未來是將 RDF 應用於電商領域，不過 RDF 更振奮人心的地方在於，它或許可以應用於各個領域。RDF 標準以及一系列相關標準，一旦得到廣泛應用，被認為可以掀開基於資料庫的軟體服務的發展，如同 HTML 為文檔出版帶來新的發展契機一般。

RDF 以及其他語義網技術似乎準備立刻接管的另一個領域是社交網路。FOAF 項目最初的名字是「 RDF 網路環 RDF Web Ring 」，是語義網發展的產物，旨在實現語義網的設想。FOAF 自誕生之初就被人們看好，有人甚至認為，FOAF 必定會淘汰掉其他社交網站。2004 年《衛報》的一篇文章這樣介紹該項目：

最初是 1996 年，SixDegrees 開始運營；接著是去年，出現了 Friendster；上周是 Orkut；下周 Flickr 也會登上舞台。這些網站不勝枚舉，都是為了建立社交網路。如今，它們處在互聯網發展的最前沿。但是，如果它們無法提供更實質性的好處，在 FOAF 標準得到廣泛應用之後，它們就會很難存活下去。 ^[2]

文章繼續指出，社交網路面臨的最大問題就是社交網站數量過多。這就需要一種能夠將所有這些網站連接起來的手段。可行方案就是 FOAF ，它終將變革整個社交網路。

根據該文章，FOAF 可將不同的社交網站緊密連接起來，實現途徑有三個要點：

• FOAF 將創建機器可讀的社交數據格式，可為各個社交網站識別讀取，避免讓用戶在不同的網站上重複輸入信息。
• FOAF 標準下， 聯繫人 Contacts （個人信息管理程序）可生成上述格式的文件，供用戶在各社交網站使用。
• FOAF 標準下，這種機器可讀的文件可寄放在個人主頁上，可為各社交網站讀取。這樣一來，用戶只需將修改過的信息推到自己的主頁，其他平台就會同步更新。

在今天可能難以想像，但在 2004 年，至少在熟悉技術的網民和技術專欄記者看來，當時社交網路並不算少，但是每個網路的用戶群體都很小。考慮到這個問題，雖然對現在的我們來說很陌生，我們就會明白為什麼需要建立單一標準是有意義的，這個標準可以使網路的激增不再是一個負擔。

FOAF 規範

根據 FOAF 項目官網現有的介紹，FOAF 是「一種計算機語言，用於生成與人相關的各種條目的字典，條目以結構化數據的形式儲存」。2000 年，FOAF 的創始人 Dan Brickley 和 Libby Miller 發表了一份關於該項目目標的文件，給出了不同的解釋，強調了 FOAF 的最終目標：作為工具，FOAF 可讓計算機像人類一樣讀取用戶主頁的個人信息 ^[3] 。FOAF 將會「幫助網路提供當前只有中心化平台才能提供的服務」 ^[4] 。通過為個人以及人際關係定義一個標準辭彙，FOAF 可以理解用戶輸入的內容，比如「找找今天推薦的醫院醫療人員」，或者「找找曾與我合作撰寫過文件的人最近發表的文章」。

由於 FOAF 是標準化的辭彙表，所以該項目最重要的成果莫過於 FOAF 規範。FOAF 規範規定了 RDF 類 和 RDF 屬性（這裡我不再解釋什麼是 RDF，如果感興趣可查閱 我關於語義網的文章）。RDF 的類由 FOAF 規範規定，表示要描述的對象，比如人（Person 類）和組織（Organization 類）。RDF 屬性由 FOAF 規範規定，表示針對不同對象所做的邏輯聲明。例如，一個人可以有一個名字（givenName 屬性）、一個姓氏（familyName 屬性），可能還有人格類型（myersBriggs 屬性）以及與他人的距離或者位置信息（based_near 屬性）。FOAF 規範的思想是，這些類和屬性要足以表示人們在個人主頁上顯示的身份信息和朋友信息。（LCTT 譯註：Myers–Briggs 即邁爾斯布里格斯類型指標，是一種人格類型理論模型。）

FOAF 規範給出了一份 FOAF 文檔的範例。該實例的格式是 XML，不過也可以使用 JSON 等格式進行編寫：

<foaf:Person rdf_about="#danbri" xmlns_foaf="http://xmlns.com/foaf/0.1/">
  <foaf:name>Dan Brickley</foaf:name>
  <foaf:homepage rdf_resource="http://danbri.org/" />
  <foaf:openid rdf_resource="http://danbri.org/" />
  <foaf:img rdf_resource="/images/me.jpg" />
</foaf:Person>

這份 FOAF 文件對一個人進行了描述，他的名字叫做 Dan Brickley（該規範的作者之一），他的主頁在 http://danbri.org，他還有個叫做「open ID」的東西，還有一張圖片在 /images/me.jpg —— 估計是 Brickley 的主頁地址的相對鏈接。FOAF 的元素名稱都會有 foaf: 前綴，表示它們是 FOAF 命名空間的一部分。相應地，RDF 的元素名稱前面也都會有 rdf:。

為了說明 FOAF 不限於 XML 格式，這裡從維基百科摘取了一個相似的例子，格式為 JSON-LD ^[5] ：

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/workplaceHomepage",
      "@type": "@id"
    },
    "Person": "http://xmlns.com/foaf/0.1/Person"
  },
  "@id": "https://me.example.com",
  "@type": "Person",
  "name": "John Smith",
  "homepage": "https://www.example.com/"
}

上面這份 FOAF 文件也描述了一個人，他的名字叫 John Smith，他的主頁在 www.example.com。

理解 FOAF 原理的最好方法可能就是體驗一下 FOAF-a-matic，一個在線生成 FOAF 文檔的工具。你可以在工具頁面的表單里輸入自己的相關信息，創建表示自己的 FOAF 文檔（XML 格式）。FOAF-a-matic 說明了 FOAF 是如何避免在註冊不同社交網站賬號時重複輸入社交信息的麻煩：如果每個社交網站都可以讀取 FOAF，你只需要在沒有註冊過帳號的網站上引用你在 FOAF-a-matic 生成的 FOAF 文檔，就可以註冊一個新帳號了。

下面這個實例是我用 FOAF-a-matic 生成的稍微複雜一些的例子，表示我自己：

<rdf:RDF
      xmlns_rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
      xmlns_rdfs="http://www.w3.org/2000/01/rdf-schema#"
      xmlns_foaf="http://xmlns.com/foaf/0.1/"
      xmlns_admin="http://webns.net/mvcb/">
  <foaf:PersonalProfileDocument rdf_about="">
    <foaf:maker rdf_resource="#me"/>
    <foaf:primaryTopic rdf_resource="#me"/>
    <admin:generatorAgent rdf_resource="http://www.ldodds.com/foaf/foaf-a-matic"/>
    <admin:errorReportsTo rdf_resource="mailto:leigh@ldodds.com"/>
  </foaf:PersonalProfileDocument>
  <foaf:Person rdf_ID="me">
    <foaf:name>Sinclair Target</foaf:name>
    <foaf:givenname>Sinclair</foaf:givenname>
    <foaf:family_name>Target</foaf:family_name>
    <foaf:mbox rdf_resource="mailto:sinclairtarget@example.com"/>
    <foaf:homepage rdf_resource="sinclairtarget.com"/>
    <foaf:knows>
      <foaf:Person>
        <foaf:name>John Smith</foaf:name>
        <foaf:mbox rdf_resource="mailto:johnsmith@example.com"/>
        <rdfs:seeAlso rdf_resource="www.example.com/foaf.rdf"/>
      </foaf:Person>
    </foaf:knows>
  </foaf:Person>
</rdf:RDF>

本例中，主要信息之前有很多其他內容，用於設置文檔使用的各種 XML 命名空間。其中就有文檔生成工具的信息，這樣用戶就能明白出了問題要向誰進行反饋。foaf:Person 元素給出了我的名字、電子郵箱和主頁。其中嵌套了 foaf:knows 元素，說明我有個叫 John Smith 的朋友。

該例還體現了 FOAF 文檔的另外一個重要功能：相互關聯。還記得之前 John Smith 的例子嗎？他的主頁在 www.example.com。在我的這個例子中，我將 John Smith 列在了 foaf:person 元素里，上一級元素是 foaf:knows，表示我認識的人。此外，我還加入了 rdfs:seeAlso 元素，放了 John Smith 主頁的 FOAF 文檔鏈接。由於加入了這一鏈接，程序在讀取我的 FOAF 文檔時，就能根據該鏈接讀取他的 FOAF 文檔，查找到更多關於 John Smith 的信息。在之前 John Smith 的 FOAF 文檔里，John 並沒有提供任何有關朋友的信息（包括我在內），這意味著程序無法確定我們兩人之間的朋友關係。但如果他加入了朋友信息，程序在讀取我的文檔之後，不僅會發現我，也會發現 John、他的朋友、他的朋友的朋友，以此類推，直到程序窮盡我和 John 各自的社交圖譜。

對於使用過 Facebook 的人來說這似乎很熟悉，也就是說，這個功能對你來說也應該很熟悉。FOAF 沒有 foaf:wall 屬性和 foaf:poke 屬性，無法完美複製 Facebook 的功能。很明顯，FOAF 也沒有漂亮的藍色界面，無法為用戶提供可視化的 FOAF 社交網路，它只是一個辭彙表。不過，Facebook 的核心功能（我認為這正是 Facebook 壟斷能力的關鍵）在這裡是以分散式的方式提供的。在 FOAF 標準下，好友可以將 FOAF 文檔上傳至個人主頁，數字化展示他們真實的社交圖譜，用戶無需將個人數據的控制權交給 Facebook 這樣一個中心化的資料庫。要知道，由於對用戶個人數據管理不當，扎克伯格大多數時間都在國會委員會前在向公眾道歉。

暫時擱置的 FOAF

瀏覽 FOAF 項目主頁，你會發現在頁面的右上角，有一張喜劇動畫《 飛出個未來 Futurama 》主角弗萊躺在休眠艙內的圖片。這張圖片是《飛出個未來》試播劇集的劇照，講的是弗萊在 1999 年不小心跌進了低溫休眠艙，直到 2999 年才再次蘇醒過來的故事。我曾和 Brickley 在 Twitter 上簡短地聊了一下，他告訴我，掛這張圖片是為了告訴人們，未來 FOAF 項目目前「處於停滯狀態」，儘管他希望將來有機會恢復這個項目，繼續探索 21 世紀初關於網路運作方式的設想。

FOAF 從未像《衛報》期望的那般徹底改變社交網路。一些社交網站選擇支持 FOAF 標準，比如 LiveJournal 和 MyOpera ^[6] 。FOAF 甚至還在 2004 年 霍華德·迪恩 Howard Dean 競選總統時發揮了一定作用：一群博主和程序員合力搭建起了一個將網站連接起來的網路，稱其為「 迪恩空間 DeanSpace 」，幫助迪恩競選，並在網站上使用 FOAF 記錄迪恩的支持者和幫助迪恩競選的志願者 ^[7] 。不過，今天人們了解到 FOAF 主要還是因為它是 RDF 應用最為廣泛的辭彙表之一，而 RDF 正是現代網路的一個重要標準。如果在今天還能用到 FOAF 的話，可能就是谷歌「 知識面板 knowledge panels 」所用技術的原型。知識面板是在用谷歌搜索時，出現在搜索結果右側的一小塊內容，會提供搜索關鍵詞的基本信息。谷歌為推行其知識面板，使用了語義網項目的「後繼者」 schema.org 項目發布的辭彙表 ^[8] 。schema.org 用來描述人物的辭彙表似乎有著 FOAF 的影子，兩者的目的大多也是相同的。

那麼，為什麼 FOAF 還是失敗了呢？為什麼人們都在用 Facebook 呢？且不提 FOAF 只是一個簡單的標準，沒有 Facebook 那麼豐富的功能，如果 FOAF 發展勢頭保持下去，很有可能就會出現相關軟體和應用，帶來像 Facebook 那樣的體驗。問題是，在 Facebook 還未發展到能與之分庭抗禮之時，FOAF 這股分散式社交網路的新生力量為什麼沒能得到廣泛應用呢？

恐怕這個問題可能沒有唯一的答案，不過非要我說的話，我覺得最關鍵的一點是，只有在每個人都有個人網站的情況下，FOAF 才有意義。在上世紀末本世紀初，人們理所當然地覺得網路最終會出現這種情況，因為就我所知，互聯網的早期用戶多是高產的博客寫手、參政的技術專家，他們都希望能有個自己的平台。但是，現實情況卻是，普通用戶並不願意學習怎麼搭建和運營網站。FOAF 允許你掌控自己的社交信息並將其推送到各類社交網路上，省去了到處註冊賬號的麻煩。如果你已經有了儲存社交信息的個人網站，那麼這個想法應該很誘人。但實際上，相比較於買域名、折騰 XML 文檔，大多數人覺得填寫信息、註冊 Facebook 賬號來得更容易些。

那麼，這與我最初的問題（Facebook 是否屬於自然壟斷）有什麼相關呢？我不得不承認，FOAF 的案例說明，社交網路 的確 擁有自然壟斷屬性。

其實，關於用戶不願管理自己的數據這一問題，本身並沒有那麼重要，因為通過讓普通用戶在熟悉技術的用戶所設置的節點上儲存個人信息，Mastodon 等現代分散式社交網路已經解決了這個問題。這也表明，人們多麼不願意折騰複雜的東西。對去中心化社交網路來說，這無疑是個壞消息，因為相較於中心化網路，去中心化網路更為複雜，用戶對此再清楚不過了。

對於 FOAF：如果我要寫一個能讀取個人網站上 FOAF 數據的程序，假設 Sally 的 FOAF 文檔提到了 John Smith，說他的主頁是 example.com；Sue 的 FOAF 文檔也提到了 John Smith，說他的主頁是 example.net。在這種情況下，我應該怎麼辦呢？到底是只有一個 John Smith 而他正好有兩個主頁呢，還是這兩個 John Smith 是不同的人呢？如果兩個 FOAF 文檔中 John Smith 的郵箱都是 johnsmith@gmail.com，又該怎麼辦呢？這種身份問題是 FOAF 的軟肋。在一封 2003 年的郵件里，Brickley 寫道，由於不存在而且可能也不應該存在一個「全球性的身份識別系統」，FOAF 採取的方法只能是「多元的」 ^[9] 。FOAF 用戶的郵件地址和主頁地址等部分屬性具有特殊性，因為郵件地址和主頁地址都是獨一無二的。因此，這些內容不可能相同的屬性可以將人們的多個 FOAF 文檔合併起來（用 Libby Miller 的話來說，「擠」在一起）。不過這些特殊屬性不存在所謂優先順序的說法，所以前面 John Smith 的問題還是不好解決。換句話說，是該相信主頁，判定他們不是同一個人呢？還是要相信郵件地址，判定他們是同一個人呢？我真的能夠在不干擾到用戶的前提下，寫出一個程序，解決這類問題嗎？

Facebook 擁有單一的資料庫，不用顧慮政治性問題，有條件創建「全球性的身份識別系統」，給每個人發行獨一無二的身份 ID，於是問題就迎刃而解了。

如果人們真的在乎對自己數據的持有權和掌控權，單是因為複雜難解應該不足以導致分散式社交網路的失敗。但是 FOAF 的失敗表明，人們從未重視過對自己數據的掌控權。正如一位博主所說，「所謂『用戶想要擁有自己的數據』只不過是一個想法，和實際應用沒有關係」 ^[10] 。如果用戶對控制的重視程度不足以承受額外的複雜性，如果中心化系統比去中心化系統更為簡單易用，如果中心化系統有發展為封閉系統的趨向，藉此取得成功，從而享受網路效應帶來的巨大效益，那麼社交網路確實屬於自然壟斷。

即便如此，我認為地鐵系統的案例和社交網路的案例仍存在不同之處。我可以欣然接受 MTA 對地鐵交通的壟斷，因為我希望地鐵系統本身就應該是長期壟斷行業。如果紐約地鐵只有一家運營商，那麼它只能是政府，至少在名義上，政府比沒有競爭對手的私企更加負責。但是我卻不希望社交網路屬於自然壟斷。地鐵建好了基本上就是一成不變的，但數字世界卻在不斷演變發展。在今天，分散式社交網路也許比中心化網路更加複雜，就好比帶兩張地鐵卡總是比只帶一張要麻煩的多。不過，在未來，互聯網會發生根本性變革，那時分散式技術將會更易於使用。

如果未來果真如此，FOAF 可能會作為建立分散式社交網路的第一次嘗試為人們記住。在企業大型資料庫所驅動的中心化網路時代結束之後，分散式網路將會得到人們的長期青睞。

如果你喜歡這篇文章，歡迎關注推特 @TwoBitHistory，也可通過 RSS 饋送 訂閱，獲取更多最新文章。

1. 請注意，這裡我沒有用「消亡」一詞。 ↩︎
2. Jack Schofield, 「Let』s be Friendsters,」 The Guardian, February 19, 2004, accessed January 5, 2020, https://www.theguardian.com/technology/2004/feb/19/newmedia.media. ↩︎
3. Dan Brickley and Libby Miller, 「Introducing FOAF,」 FOAF Project, 2008, accessed January 5, 2020, https://web.archive.org/web/20140331104046/http://www.foaf-project.org/original-intro. ↩︎
4. 同上。 ↩︎
5. Wikipedia contributors, 「JSON-LD,」 Wikipedia: The Free Encyclopedia, December 13, 2019, accessed January 5, 2020, https://en.wikipedia.org/wiki/JSON-LD. ↩︎
6. 「Data Sources,」 FOAF Project Wiki, December 11 2009, accessed January 5, 2020, https://web.archive.org/web/20100226072731/http://wiki.foaf-project.org/w/DataSources. ↩︎
7. Aldon Hynes, 「What is Dean Space?」, Extreme Democracy, accessed January 5, 2020, http://www.extremedemocracy.com/chapters/Chapter18-Hynes.pdf. ↩︎
8. 「Understand how structured data works,」 Google Developer Portal, accessed January 5, 2020, https://developers.google.com/search/docs/guides/intro-structured-data. ↩︎
9. tef, 「Why your distributed network will not work,」 Progamming is Terrible, January 2, 2013, https://programmingisterrible.com/post/39438834308/distributed-social-network. ↩︎
10. Dan Brickley, 「Identifying things in FOAF,」 rdfweb-dev Mailing List, July 10, 2003, accessed on January 5, 2020, http://lists.foaf-project.org/pipermail/foaf-dev/2003-July/005463.html. ↩︎

via: https://twobithistory.org/2020/01/05/foaf.html

作者：Two-Bit History 選題：lujun9972 譯者：aREversez 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive